General Packet Radio Service (GPRS) Tunneling Protocol (GTP) is a group of Internet Protocol (IP)-based communications protocols that are used to carry GPRS within Global System for Mobile (GSM) and Universal Mobile Telecommunication Service (UMTS) networks, including Long Term Evolution (LTE) networks.
In such networks, different variants of GTP may be implemented by the various network elements of the networks. For example, different variants of GTP may be implemented by Radio Network Controllers (RNCs), Serving GPRS Support Nodes (SGSNs), Gateway GPRS Support Nodes (GGSNs), Serving Gateways (SGWs), Packet Data Network (PDN) Gateways (PGWs), xGWs (e.g., nodes supporting one or both of Serving Gateway (SGVV) and Packet Data Network (PDN) Gateway (PGW) capabilities), Charging Gateway Functions (CGFs), and the like.
There are several variants of GTP, including: GTP Control (GTP-C), GTP User Data Tunneling (GTP-U), and GTP prime (GTP').
GTP-C is used within the GPRS Core Network for signaling between GGSNs/PGWs and SGSNs/SGWs. This allows the SGSN/SGW to activate sessions on behalf of users (e.g., PDP context activation), to deactivate sessions on behalf of users, to update a session for a user who has just arrived from another SGSN/SGW, to adjust quality-of-service parameters, and the like.
GTP-U is used for carrying user data within the GPRS Core Network and between the GPRS Radio Access Network and the GPRS Core Network. The user data that is transported can be packets in any of IP version 4 (IPv4), IP version 6 (IPv6), or Point-to-Point Protocol (PPP) formats.
GTP is used for carrying charging data from the Charging Data Function (CDF) of the GSM or UMTS network to the Charging Gateway Function (CGF). In most cases, this should mean from many individual network elements, such as the GGSNs, to a centralized computer that delivers the charging data more conveniently to the billing center of the network operator.
GTP-C, GTP-U and GTP use a common message structure for performing their various functions.
In general, GTP Messages may be broken down into two categories as follows: GTP Initial Messages and GTP Triggered Messages.
GTP Initial Messages are messages originated by a GTP entity not based on any other GTP Message. For example, GTP Initial Messages include messages such as the Create Session Request message, the Modify Bearer Request message, the Bearer Resource Command message, the Modify Bearer Command message, and the like.
GTP Triggered Messages are messages that are generated as a result of a received GTP Message (e.g., such as a GTP Initial Message). For example, GTP Triggered Messages include messages such as the Create Session Response message, the Create Bearer Response message, the Create Bearer Request Modify Bearer Command message, the Update Bearer Request—in response to Modify Bearer Command message, and the like.
GTPv2 has been developed for use with evolved packet services. GTPv2 uses sequence numbers as transaction identifiers. The sequence numbers are used to correlate the response messages with the corresponding request messages. The response messages have the same sequence number as those of the corresponding request messages that triggered them. Typically, the GTP Messages (i.e., request and response) triggered by a GTP command have the same sequence number as that of the GTP command, and the sequence numbers used for the GTP commands have the most significant bit set (as do the request and response messages triggered by that command). Typically, the GTP Messages not triggered by the GTP commands do not have the most significant bit set (in order to avoid potential sequence number clashes). The sequence numbers for all outstanding transactions with a GTP peer are unique, and they are not reused until those transactions are completed, plus a time interval which is used to ensure that delayed request or response messages, if any, do not cause any issues.
In many implementations of nodes configured for processing GTP Messages, the node includes a central processing module (CPM) and multiple processing entities. The CPM is configured for receiving GTP Messages and providing them to the processing entities to be processed, and the processing entities are configured for processing the GTP Messages. In this sense, the control plane is distributed (e.g., possibly across multiple cards within a chassis and/or multiple tasks within the cards). In existing nodes, all incoming GTP Messages received at a node are routed to the appropriate processing entity of the node based on a value of the Tunnel Endpoint Identifier (TEID) in the GTP message header of the GTP Message, with the exception of incoming GTP Messages having an invalid TEID (e.g., unknown TEID value or a TEID value of zero) in the GTP message header, which are processed at the CPM. For example, an incoming Create Session Request (e.g., INITIAL_ATTACH at SGW or PDN_CONNECTION_REQUEST at PGW) with a TEID value of zero is processed at the CPM, and is then redirected to one of the processing entities based on various load-balancing considerations.
This process works well for GTP Initial Messages, and for most GTP Triggered Messages (which typically have a non-zero value of TEID which allows them to be routed to the appropriate processing entity). However, in some cases, when the GTP entity generating a GTP Triggered Message loses context of the session, the GTP entity, not knowing what to do with the GTP Triggered Message, sends an error message with a cause code of “Context Not Found” and a TEID value of zero (0). Similarly, in some cases, when the GTP entity generating a GTP Triggered Message loses context of the session, the TEID value included within the GTP Triggered Message is unknown or otherwise invalid. In such cases, it is not possible for the CPM of the node that receives the GTP Triggered Message to route the GTP Triggered Message to the appropriate processing entity based on the TEID. As a result, the CPM must process the GTP Triggered Message. This may lead to a condition in which the CPM is unduly burdened by processing of such messages (e.g., when too many “lost context” GTP Triggered Messages are received), such that the GTP Triggered Messages are not processed properly or timely and/or such that other CPM processing tasks are neglected.